At present, in transmission of video data on the Internet, there are down-load type transmission system and stream type transmission system (hereinafter referred to as Streaming). In the down-load type transmission system, video file transmitted from distribution server is once (temporarily) copied at the client terminal (device) side, and data (video data) of video file is then reproduced. For this reason, in this down-load type transmission system, it is impossible to carry out reproduction of data at the terminal side until transfer of file is completed. Therefore, this down-load type transmission system is unsuitable for reproducing video data, etc. for long time.
On the other hand, the streaming is such that the client terminal sequentially reproduces successive flow of digital signals on the real time basis while receiving it. Also for a time period during which transmission from stream server to client terminal is carried out, reproduction of received data is performed at the client terminal side. As this streaming system, streaming using protocol RTP (Real-Time Transport Protocol) prescribed in RFC 1889 of IFTF (Internet Engineering Task Force) is the main current.
Ordinarily, the streaming system is composed of an authoring unit, a stream server, and client terminals. The authoring unit is supplied with encrypted contents data obtained by compression-encoding music or video data (hereinafter referred to as contents data) inputted from image input means, etc., e.g., camera or VTR (Video Tape Recorder), etc. and encrypting such contents data by the so-called contents key at encryption unit to prepare, from this encrypted contents data, data for distribution of stream in a form that the distribution (delivery) system determines.
The stream distribution data is such that, e.g., header information for adding header which describes information according to the entirety of contents data, header information for adding track every kind of data, etc. to contents data, and additional information including Session Description Protocol (SDP) file prepared in accordance with Session Description Protocol (SDP) (RFC 237) and packeting control information, etc. are added to encrypted contents data. The stream distribution data prepared in this way is recorded with respect to, e.g., recording unit, etc. of recording medium, etc. such as optical disc, etc. that the authoring unit has. Further, when a request for use of contents is given from the client terminal, this stream distribution data is suitably taken out from the recording unit, and is delivered to the stream server. Thus, Session Description Protocol (SDP) file is transmitted from the stream server to the client terminals.
The client terminal acquires information such as address, port No. and packet form for reception of stream from Session Description Protocol (SDP) file. Then, the stream server packets stream distribution data on the basis of packeting control information to distribute data (stream) to client terminals, e.g., PC (Personal Computer), etc. every packet in accordance with RTP and RTSP (Real-Time Streaming Protocol) to allow the client terminals to perform real time reproduction.
In the conventional streaming method, in packeting encrypted stream data (encrypted contents data) from the stream server to distribute it to the client terminals, Contents Key for decoding this encrypted packet data is required for the client terminal. Namely, before streaming, the client terminal is required to share Contents Key for decoding encrypted contents data caused to undergo stream distribution into contents data with encryption unit in which encrypted contents data is prepared. However, when information of Contents Key is written into Session Description Protocol (SDP) file, since Session Description Protocol (SDP) file is not ordinarily encrypted, there is the problem that information of Contents Key appears so that safety lacks.